Subject: IBM DLSw activity

From: "David Miller (254-5752)" <[email-masked]>
Date: Mon, 10 May 93 14:53:43 EDT

Fellow DLSw-SIG members:

I will be the interface for DLSw development in the DLSw-SIG.  I will
be handling questions from you and providing answers.  If I don't know
the answer, then I will tap the resources of the DLSw team.  I would
like to welcome all members to this SIG.  I'm sorry that I haven't been
involved earlier, but I have been a bit under the weather for the
past few days.

I am a member of the DLSw development team, specifically assigned
to work on SDLC protocols.

Since Wayne has already begun the creation of a function matrix, I
would like to inform you of IBM's efforts regarding all the functions
within it.

1.  Flow Control

As stated previously by Dennis Wind in this forum, we are developing
an end-to-end mechanism for flow control that DLSw manages.  In our
mechanism, flow control is implemented by a new field in the SSP header.
This field resides at offset 1 and was previously marked as reserved.
It is piggybacked on all I-frames.  The format of the field is:

  76543210
  X.......  -  Pacing Request Indicator (PREQ)
  .X......  -  Pacing Response Indicator (PRSP)
  ..X.....  -  Decrement Window Size Indicator (DWSI)
  ...X....  -  Inrement Window Size Indicator (IWSI)
  ....X...  -  Close Window Indicator (CWI)
  .....X..  -  Don't Count Frame Indicator (DCFI)
  ......XX  -  Reserved

There are three new SSP's:

  IPM (x'7C')
  ENTERBUSY (x'0C')
  EXITBUSY (x'0D')

A pacing window is defined for each circuit.  Management of this window
is modelled after the VR windows defined for SNA NT 4.
 - PREQ is set if the maximum number of I-frames has been received
   from the LAN without receiving either a IPM SSP or an I-frame with
   PRSP set.
 - PRSP is set on the next WAN-bound frame if PREQ has been previously
   received on a I-frame on that circuit.  PRSP received on a circuit
   will clear any local RNR condition.
 - DCFI is only set if pacing is not in use, i.e. the pacing window
   defined was set to zero.
 - DWSI and IWSI have been defined for adaptive pacing.
   DWSI is set in conjunction with PRSP to cause the partner to halve
   the pacing window.
   IWSI is set in conjunction with PRSP to cause the partner to increment
   the pacing window.
 - CWI usage has not been defined yet.
 - IPM is sent to the circuit partner if a PREQ has been
   received and there is no I-frame to piggyback the PRSP on.
 - ENTERBUSY is sent to the circuit partner on detection of a remote
   RNR condition.  This will cause the circuit partner to enter a local
   RNR condition.
 - EXITBUSY is sent to the circuit partner when a remote RNR condition
   clears.  This will cause the circuit partner to exit a local
   RNR condition.

2.  NT 2.1

We are developing a mechanism for NT 2.1 that allows primary,
secondary, or negotiable attachment of a NT 2.1 device to the 6611.
This mechanism will allow SDLC-to-SDLC connectivity.  (We are
investigating this mechanism for use with other NT types including
NT 2.0 and NT 4)  In this mechanism, we map the SDLC flows to the
token ring flows as in the following scenario in which both
6611's are negotiable:

NT 2.1             6611                 6611                NT 2.1
XID3
-------------------->*                   *
XID3
-------------------->*                   *
                              .
    time passes               .
                              .
                      CURFRAME
                     *------------------>*
                                 ICRFRAME
                     *<------------------*
                      RESPACK
                     *------------------>*
XID3                   XIDFRAME           XID3
-------------------->*------------------>*------------------->*
                 XID3          XIDFRAME                  XID3 |
<--------------------*<------------------*<-------------------+
                              .
                              .
                              .
XID3                   XIDFRAME           XID3
-------------------->*------------------>*------------------->*
                 XID3          XIDFRAME                  XID3 |
<--------------------*<------------------*<-------------------+
SNRM                   CONTACT                           SNRM
-------------------->*------------------>*------------------->*
                  UA          CONTACTED                   UA  |
<--------------------*<------------------*<-------------------+
RR                                        RR
-------------------->*                   *------------------->*
                  RR |                                     RR |
<--------------------+                   *<-------------------+
                    I              IFRAME                    I
<--------------------*<------------------*<--------------------
|                RR                      |                 RR
+------------------->*                   +-------------------->

Note that all XID negotiation is performed at the EN for SDLC-to-SDLC
connections.

We have a prototype of this connection functioning correctly.

3.  Ethernet

In MPNP V1R1.1.2, we have developed a mechanism for transport of ethernet
traffic using DLSw.  In this mechanism, Ethernet frames are converted
into TR frames by converting the canonical addresses to non-canonical and
by inserting a routing information field.

4.  Priority & 5. COS

Are we talking SNA COS or COS on the TCP/IP connection?  If SNA COS,
are we talking priorities given to particular sessions types or
only INN priorities?  If on the TCP/IP connection, COS for different
protocol types?  Priorities for different protocol types?
Of course any discussion of them is welcome.

6.  Capability Exchange

IBM first submitted this requirement.  It would be desireable for the
DLSw partners to exchange capabilities information (as in XIDs for
NT 2.1)  In this manner, the two partners could determine such
things as pacing windows, pacing usage, ...)

7.  Conformance

IBM is considering offering such a service.  We envision it to be:

     1.  You install your equipment in our labs
         (If our facilities are used, there will probably be some
         kind of charges involved.  Of course, this will still be
         cheaper than buying your own 3090 :-)

     2.  Run predefined tests.  If your equipment passes, then
         certification is guaranteed.  If not, you will be given
         a chance to correct any deficiencies and retry.

Of course, new IBM equipment will be subject to the same predefined
tests.  These tests would be defined as part of the work of the
DLSw-SIG.

8.  Greater support for SDLC devices

As I stated above, we are investigating SDLC attachment as
secondary, primary, or negotiable for all NT types.

9.  Channel

We are investigating channel connectivity.

10.  Subarea Transmission Groups

We are currently investigating INN connectivity options.  Single
link TG (SLTG) is currently under development and will follow
the same type flows as the NT 2.1 discussed above.
MLTG is under investigation.

We have a working prototype of a NT 4 connection.

11.  Directory support for configuration information

We are currently investigating this item.

12.  Alternate transport

IBM is currently investigating the use of RTP/HPR from APPN as an
alternative to TCP/IP providing reliable transport from end-to-end.

13.  Security

Exactly what kinds of security must be provided for DLSw?  I don't
quite understand the requirement.

14.  DLSw-APPN integration

We are currently investigating this item.  At first glance, it appears
that this would involve some sharing of directory services.

15.  MIB

We have a MIB defined for the DLSw.  Details of the MIB may be found in
"6611 Network Processor Network Management Reference," doc number
GC30-3567-00.  This MIB is subject to change based on requirements from
our users.  In addition, any suggestions for improvement will be
investigated.

In addition, I will place a copy of the MIB on an anonymous ftp site.
Details for accessing it are as follows:
---------------------------------------------------------------------
Accessing the 6611 Anonymous FTP Site

To provide you with greater access to information about
and updates to the 6611 Configuration Program,
the 6611 anonymous FTP site has been established.  Customers with
Internet access can FTP to
6611ftp.cary.ibm.com (192.35.236.5).
Type user anonymous to login.
When prompted for a password, type your e-mail address.

After you login, refer to the read.me file for information about the
anonymous FTP site and its directory tree.
It is also important that you read and agree to abide by the terms and
conditions of the IBM license agreement in the
/pub/misc/license.txt file.

The following information will be initially available on the
6611 FTP site:

The Configuration Program, V1 R1.0 (PTF 273, available 4/27/93)
and V1 R1.1
PTFs for the Configuration Program
RCF 1434 (data link switching) and the informational RFC that
describes how APPN operates over TCP/IP

Additional information will also become available.
Watch subsequent 6611 Information Updates for details.
---------------------------------------------------------------------

There was a question awhile back regarding TEST frames and SDLC.  The 6611 MPQP adapter
will reject a received TEST frame as a protocol violation.  Yes, use of the TEST
frame is architected;  however, it is never used.  Most devices (if not all) do not
send/receive TEST frames on SDLC lines.

Please, I welcome any discussion of IBM's plans for DLSw.  I will
attempt to answer any questions you may have.

David Miller

---

From: [email-masked]
Date: Tue, 11 May 93 13:36:51 PDT

David -

    The goal of an open working group such as the DLSw SIG is that all
    members participate equally and that no one company attempt to
    dominate the process.  The tone of your statement below is one of
    IBM telling the other members of the SIG how things work.  If this
    is done from the perspective of an IBM rep to the SIG, that is
    fine.  If is done from the perspective of "we've got it all figured
    out and here is how it's done", then the openness of this SIG is in
    question.

    In its present form, the AIW itself is really a tutorial with a
    suggestion box.  IBM sets the agenda and other companies pretty
    much follow along.  This is because with APPN, IBM is in direct
    control.  The DLSw SIG is different in that the member companies
    already have shipped products in this area and we are attempting to
    achieve some degree of convergence and interoperability.  That was
    our original intent and it still is today.

    My prior statements regarding STUN (cisco's SDLC-to-SDLC) were in
    the spirit of: here is what we've discovered in this market and
    we're willing to share our experiences with the SIG.  It is
    presumptious for any one of the vendors in this market to assume
    they have it all figured out.

    If you look at the way working groups in the IETF operate, there
    are usually implementations from a small finite number of vendors
    and those vendors work together to form a consistent, interoperable
    standard.  This means that ALL vendors have to be flexible.  The
    same level of consideration must be given to this effort.

    I'm not intending to start an email war here ... I just want to
    make sure we retain the level playing field we started with.

Regards,
-----------
Wayne Clark
cisco Systems, Inc.
[email-masked]
415/688-4627